home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 557 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.7 KB

  1. Path: chronicle.mti.sgi.com!austern
  2. From: jamshid@io.com (Jamshid Afshar)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Destruction of singletons
  5. Date: 26 Feb 1996 18:08:20 PST
  6. Organization: Illuminati Online, Austin, Texas, USA
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4gtmg0$t59@pentagon.io.com>
  9. References: <4fvng1$jit@netlab.cs.rpi.edu> <4go9au$l8f@engnews1.Eng.Sun.COM> <9602261828.AA28873@lts.sel.alcatel.de>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 26 Feb 1996 19:24:16 -0600
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBVAwUBMTJnn0y4NqrwXLNJAQHYGAH+Jnn023ajGxidobGrMaPHlfu8vrlPm+Ox
  14.     z2gn4NEHpHtOOmrK2i7oP9EPs6DGsJEAptPMpCKcXA7cZ1klGdc2LQ==
  15.     =6qph
  16. Originator: austern@isolde.mti.sgi.com
  17.  
  18. In article <9602261828.AA28873@lts.sel.alcatel.de>,
  19. James Kanze US/ESC 60/3/141 #40763  <kanze@lts.sel.alcatel.de> wrote:
  20. >In article <4go9au$l8f@engnews1.Eng.Sun.COM> Jamshid Afshar
  21. ><jamshid@IO.COM> writes:
  22. >
  23. >1. As long as there is an active pointer to the memory (a static
  24. >pointer), Purify will not classify it as a leak.
  25.  
  26. You're right.  I thought there was some kind of report of all unfreed
  27. memory at program exit.
  28.  
  29. >In general, I would stress that the prefered solution is to not use
  30. >the singleton object in any destructors, and use a local static to
  31. >initialize the pointer.  If you do have to use the object in
  32. >destructors, however, I would still prefer not destructing it to
  33. >trying to manage the `order of destruction' problem (given that most
  34. >compiler implementors still consider the order of destruction of
  35. >static locals undefined).
  36.  
  37. I agree I would rather have the compiler manage the destruction,
  38. especially since it's so easy for them to do it (just generate a
  39. "destroy" function and register it with atexit() when the constructor
  40. returns).
  41.  
  42. >|> Actually, the construction and destruction of "local objects of static
  43. >|> storage duration" is not the same as objects outside of functions.  In
  44. >|> fact, it seems local statics are more poorly specified.  According to
  45. >|> the April '95 Draft, while they are guaranteed to not be constructed
  46. >|> until (and if) the function is called, exactly when the destructor is
  47. >|> called is unspecified.
  48. >
  49. >I actually believe that it is, and in fact, has been well defined from
  50. >the ARM.
  51.  
  52. Okay, I see now that I was misreading section 6.7 Declaration
  53. Statement in the ARM and April 95 Draft.  I took the sentence "Exactly
  54. when is unspecified" to mean the destructor order is *completely*
  55. unspecified.  I guess the sentence is only referring to the previous
  56. sentence (ie, "Whether the destructor is called before or as part of
  57. the atexit() functions is unspecified.").
  58.  
  59.    5 The destructor for a local object with static storage duration will be
  60.      executed if and only if the variable was constructed.  The  destructor
  61.      is  called  either  immediately  before or as part of the calls of the
  62.      atexit()  functions  (_lib.support.start.term_).   Exactly   when   is
  63.      unspecified.
  64.  
  65. >In any case, the Jan. 96 draft makes the question moot, since it
  66. >explicitly adds the words in the destructor section clarifying that
  67. >static means both local and non-local.
  68.  
  69. I assume you're referring to 3.6.3 Termination (analogous to ARM 3.4
  70. Start and Termination).  Btw, has the wording in 6.7 been changed or
  71. improved?  There seems to be some conflict with it and 3.6.3 wrt the
  72. order of static destructors and atexit() calls.
  73.  
  74. >|> [...] What should
  75. >|> have been required IMO is that local statics be destroyed in the
  76. >|> reverse order they were (fully) constructed. 
  77. >
  78. >I agree.  The remaining weak point in the standard is that it doesn't
  79. >really specify what is meant by the ordering, entering the
  80. >constructor, or leaving it.
  81.  
  82. If the Standard does not require local statics to be destroyed in the
  83. reverse order they were *fully* constructed, local statics are useless
  84. to the many programmers who have singletons that use another singleton
  85. during its construction and destruction (eg, all singletons may report
  86. their construction and destruction to a "logfile" singleton).
  87. Programmers will instead have to dynamically create the singletons and
  88. either never delete them or use the "atexit(&destroy)" technique I
  89. mentioned.  The "atexit(&destroy)" technique isn't difficult (you can
  90. even wrap it up in a template), but it seems silly for this to be 1)
  91. unspecified and 2) specified in a manner that makes local statics so
  92. much less useful.
  93.  
  94. Jamshid Afshar
  95. jamshid@io.com
  96. ---
  97. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  98.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  99.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  100.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  101.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  102. ]
  103.